home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_4_08.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
89KB
|
4,497 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.LP
\fB13\fR \fBData transfer phase\fR
.sp 1P
.RT
.sp 2P
.LP
13.1
\fINormal data transfer service\fR
.sp 1P
.RT
.sp 1P
.LP
13.1.1
\fIFunction\fR
.sp 9p
.RT
.PP
The normal data transfer service allows both SS\(hyusers to
transfer NSSDUs over the session connection. The SS\(hyprovider should deliver
each NSSDU to the SS\(hyuser as soon as possible. This service is always
available on every session connection.
.PP
Use of this service is subject to the token restrictions specified in Table\
8/X.215.
.RT
.sp 1P
.LP
13.1.2
\fITypes of\fR
\fIprimitives\fR \fIand their parameters\fR
.sp 9p
.RT
.PP
Table 10/X.215 specifies the types of session service primitives
and parameters needed for normal data transfer.
.RT
.ce
\fBH.T. [T10.215]\fR
.ce
TABLE\ 10/X.215
.ce
\fBNormal data transfer primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 10/X.215 [T10.215] p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
\fISS\(hyuser data\fR parameter is an NSSDU. The size of an NSSDU is an
integral number of octets greater than zero and unlimited in length.
.sp 1P
.LP
13.1.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful normal data transfer is defined
by the time sequence diagram shown in Figure\ 6/X.215.
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 6/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.2
\fIExpedited data transfer service\fR
.sp 1P
.RT
.sp 1P
.LP
13.2.1
\fIFunction\fR
.sp 9p
.RT
.PP
The expedited data transfer service allows SS\(hyusers to transfer
XSSDUs over the session connection. The transfer of an XSSDU is free from
the token and flow control constraints of the normal data transfer service,
typed data transfer service and the capability data exchange service.
.PP
The SS\(hyprovider guarantees that an XSSDU will not be delivered after
any subsequently submitted NSSDU or TSSDU on that session connection. The
size of an XSSDU is limited.
.RT
.sp 1P
.LP
13.2.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 11/X.215 specifies the types of session service primitives
and parameters needed for expedited data transfer.
.RT
.ce
\fBH.T. [T11.215]\fR
.ce
TABLE\ 11/X.215
.ce
\fBExpedited data transfer primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 11/X.215 [T11.215] p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
\fISS\(hyuser data\fR \| parameter is an XSSDU. The size of an XSSDU is\
1 to 14\ octets.
.sp 1P
.LP
13.2.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful expedited data transfer is defined
by the time sequence diagram shown in Figure\ 7/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 7/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.3
\fITyped data transfer service\fR
.sp 1P
.RT
.sp 1P
.LP
13.3.1
\fIFunction\fR
.sp 9p
.RT
.PP
The typed data transfer service permits the SS\(hyusers to transfer
TSSDUs over the session connection. Typed data transfers are subject to the
same service restrictions as normal data transfers, except that typed data
transfers are not subject to token restrictions.
.bp
.RT
.sp 1P
.LP
13.3.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 12/X.215 specifies the types of session service primitives
and parameters needed for the typed data transfer service.
.RT
.ce
\fBH.T. [T12.215]\fR
.ce
TABLE\ 12/X.215
.ce
\fBTyped data primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 12/X.215 [T12.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.PP
\fISS\(hyuser data\fR \| parameter is a TSSDU. The size of a TSSDU is an
integral number of octets greater than zero and unlimited in length.
.sp 1P
.LP
13.3.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful typed data transfer is defined
by the time sequence diagram shown in Figure\ 8/X.215.
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 8/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.4
\fICapability data exchange service\fR
.sp 1P
.RT
.sp 1P
.LP
13.4.1
\fIFunction\fR
.sp 9p
.RT
.PP
The capability data exchange service allows SS\(hyusers to exchange
user data while not within an activity. The service can only
be initiated if activity services are available but no activity is in
progress. Use of this service is subject to the token restrictions specified
in Table\ 8/X.215.
.bp
.RT
.sp 1P
.LP
13.4.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 13/X.215 specifies the types of session service primitives
and parameters needed for the capability data exchange service.
.RT
.ce
\fBH.T. [T13.215]\fR
.ce
TABLE\ 13/X.215
.ce
\fBCapability data exchange primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 13/X.215 [T13.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.PP
\fISS\(hyuser data\fR is a parameter containing an unlimited number of
octets of user information.
.sp 1P
.LP
13.4.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful capability data exchange is
defined by the time sequence diagram shown in Figure 9/X.215.
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 9/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.5
\fIGive tokens service\fR
.sp 1P
.RT
.sp 1P
.LP
13.5.1
\fIFunction\fR
.sp 9p
.RT
.PP
The give tokens service allows an SS\(hyuser to surrender one or more tokens
to the other SS\(hyuser, subject to the token restrictions specified in
Table\ 8/X.215.
.PP
The initial assignment of the tokens is established when the session connection
is established (see \(sc\ 7.6.2).
.bp
.RT
.sp 1P
.LP
13.5.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 14/X.215 specifies the types of session service primitives
and parameters needed for the give tokens service.
.RT
.ce
\fBH.T. [T14.215]\fR
.ce
TABLE\ 14/X.215
.ce
\fBGive tokens primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 14/X.215 [T14.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.5.2.1\ \ \fITokens\fR \| is a list of tokens assigned to this SS\(hyuser
to be
transferred to the other user. The value is any combination of:
.sp 9p
.RT
.LP
a)
data token;
.LP
b)
synchronize\(hyminor token;
.LP
c)
major/activity token;
.LP
d)
release token.
.sp 1P
.LP
13.5.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of user information.
.sp 9p
.RT
.sp 1P
.LP
13.5.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful transfer of tokens is
defined by the time sequence diagram shown in Figure\ 10/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 10/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.6
\fIPlease tokens service\fR
.sp 1P
.RT
.sp 1P
.LP
13.6.1
\fIFunction\fR
.sp 9p
.RT
.PP
The please tokens service allows an SS\(hyuser to request specific
tokens, subject to the token restrictions specified in Table\ 8/X.215.
.bp
.RT
.sp 1P
.LP
13.6.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 15/X.215 specifies the types of session service primitives
and parameters needed for the please tokens service.
.RT
.ce
\fBH.T. [T15.215]\fR
.ce
TABLE\ 15/X.215
.ce
\fBPlease tokens primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 15/X.215 [T15.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
13.6.2.1\ \ \fITokens\fR \| is a list of available tokens not assigned to but
requested by the SS\(hyuser. The value is any combination of:
.sp 9p
.RT
.LP
a)
data token;
.LP
b)
synchronize\(hyminor token;
.LP
c)
major/activity token;
.LP
d)
release token.
.sp 1P
.LP
13.6.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.6.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful request for tokens is
defined by the time sequence diagram shown in Figure\ 11/X.215.
.RT
.LP
.rs
.sp 11P
.ad r
\fBFigure 11/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.7
\fIGive control service\fR
.sp 1P
.RT
.sp 1P
.LP
13.7.1
\fIFunction\fR
.sp 9p
.RT
.PP
The give control service allows an SS\(hyuser to surrender the entire set
of available tokens. This service is an integral part of the activity
management concept. This service can only be requested when activity management
functional unit has been selected, but no activity is in progress.
.RT
.sp 1P
.LP
13.7.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 16/X.215 specifies the types of session service primitives
and parameter needed for the give control service.
.RT
.ce
\fBH.T. [T16.215]\fR
.ce
TABLE\ 16/X.215
.ce
\fBGive Control Primitives and Parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 16/X.215 [T16.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
\fISS\(hyuser data\fR \| is a parameter containing an unlimited number
of octets of user information.
.sp 1P
.LP
13.7.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful transfer of tokens is
defined by the time sequence diagram shown in Figure\ 12/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 12/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.8
\fIMinor synchronization point service\fR
.sp 1P
.RT
.sp 1P
.LP
13.8.1
\fIFunction\fR
.sp 9p
.RT
.PP
The minor synchronization point service allows SS\(hyusers to define minor
synchronization points in the flow of NSSDUs and TSSDUs. If the activity
management functional unit has been selected, this service can only be
initiated within an activity. Use of this service is subject to the token
restrictions specified in Table\ 8/X.215.
.bp
.PP
The requestor may request explicit confirmation of a minor
synchronization point request through the use of the Type parameter. However,
the SS\(hyprovider does not require that an explicit confirmation be issued.
The acceptor may issue a confirmation even if explicit confirmation is
not
requested.
.PP
Responses are issued in the order in which the corresponding
indications were received. A further minor synchronization point request
may be made while previous minor synchronization points are unconfirmed.
.PP
The confirmation of a minor or major synchronization point confirms
all previously unconfirmed minor synchronization points. The number of
unconfirmed minor synchronization points is not limited by the SS\(hyprovider.
.PP
Any semantics associated with request and confirmation of a minor
synchronization point have no connotations to the SS\(hyprovider.
.PP
\fINote\fR \ \(em\ When the duplex functional unit is selected, additional
arrangements between SS\(hyusers may be required to correlate minor
synchronization point requests and confirms with the flow of data from the
SS\(hyuser without the synchronize\(hyminor token.
.RT
.sp 1P
.LP
13.8.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 17/X.215 specifies the types of session service primitives
and parameters needed for the minor synchronization point service.
.RT
.ce
\fBH.T. [T17.215]\fR
.ce
TABLE\ 17/X.215
.ce
\fBMinor synchronization point primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 17/X.215 [T17.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
13.8.2.1\ \ \fIType\fR \| is a parameter which indicates whether or not
explicit
confirmation is requested by the SS\(hyuser and is transparent to the SS\(hyprovider.
Its value is one of:
.sp 9p
.RT
.LP
a)
explicit;
.LP
b)
optional.
.sp 1P
.LP
13.8.2.2\ \ \fISynchronization Point Serial Number\fR \| is defined in
\(sc\ 11.4.3. It is in the range\ 0 to\ 999998.
.sp 9p
.RT
.sp 1P
.LP
13.8.2.3\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.bp
.sp 9p
.RT
.sp 1P
.LP
13.8.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives for confirmation of a minor
synchronization point is defined by the time sequence diagram shown in
Figure\ 13/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 13/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
The response and confirm may be absent even if the Type parameter is set
to explicit in the indication.
.PP
The successful confirmation of the minor synchronization point may
also be achieved by issuing (instead of the S\(hySYNC\(hyMINOR response to the
synchronization point specified in the S\(hySYNC\(hyMINOR indication):
.RT
.LP
a)
an S\(hySYNC\(hyMINOR response to a subsequent S\(hySYNC\(hyMINOR
indication;
.LP
b)
an S\(hySYNC\(hyMAJOR response to a subsequent S\(hySYNC\(hyMAJOR
indication;
.LP
c)
an S\(hySYNC\(hyMINOR request for a subsequent minor
synchronization point (provided that the synchronize\(hyminor
token has been passed from the other SS\(hyuser);
.LP
d)
an S\(hySYNC\(hyMAJOR request for a subsequent major
synchronization point (provided that the synchronize\(hyminor
token and, if necessary, the major/activity token have been
passed from the other SS\(hyuser).
.sp 2P
.LP
13.9
\fIMajor synchronization point service\fR
.sp 1P
.RT
.sp 1P
.LP
13.9.1
\fIFunction\fR
.sp 9p
.RT
.PP
The major synchronization point service allows the requestor to
define major synchronization points in the flow of NSSDUs, TSSDUs and\
XSSDUs, to completely separate the flow before and after the major synchronization
point. If the activity management functional unit has been selected, this
service may only be initiated within an activity. Use of this service is
subject to the token restrictions specified in Table\ 8/X.215.
.PP
After making the S\(hySYNC\(hyMAJOR request, the requestor is not able to
initiate any services, except for S\(hyTOKEN\(hyGIVE request, S\(hyACTIVITY\(hyINTERRUPT
request, S\(hyACTIVITY\(hyDISCARD request, S\(hyU\(hyABORT request or S\(hyRESYNCHRONIZE
request until the S\(hySYNC\(hyMAJOR confirm is received.
.PP
After receiving the S\(hySYNC\(hyMAJOR indication, in addition to any
existing restrictions, the acceptor is not able to initiate S\(hySYNC\(hyMAJOR
request, S\(hySYNC\(hyMINOR request, S\(hyACTIVITY\(hyINTERRUPT request,
S\(hyACTIVITY\(hyDISCARD request, S\(hyACTIVITY\(hyEND request or S\(hyRELEASE
request until an S\(hySYNC\(hyMAJOR
response is issued.
.bp
.PP
Expedited data transfer services initiated by the acceptor after
issuing a S\(hySYNC\(hyMAJOR response are not indicated before the S\(hySYNC\(hyMAJOR
confirm.
.RT
.sp 1P
.LP
13.9.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 18/X.215 specifies the types of session service primitives
and parameters needed for the major synchronization point service.
.RT
.ce
\fBH.T. [T18.215]\fR
.ce
TABLE\ 18/X.215
.ce
\fBMajor synchronization point primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 18/X.215 [T18.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.9.2.1\ \ \fISynchronization Point Serial Number\fR \| is defined in
\(sc\ 11.4.4.
It is in the range\ 0 to\ 999998.
.sp 9p
.RT
.sp 1P
.LP
13.9.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.9.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in the successful definition of a major synchronization
point is defined by the time sequence diagram shown in
Figure\ 14/X.215.
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 14/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.10
\fIResynchronize service\fR
.sp 1P
.RT
.sp 1P
.LP
13.10.1
\fIFunction\fR
.sp 9p
.RT
.PP
The resynchronize service is provided to assist orderly
reestablishment of communication within the current session connection,
typically following an error or lack of response by either of the SS\(hyuser or
the SS\(hyprovider, or disagreements between SS\(hyusers. Requesting the
service sets the session connection to an agreed defined state, including
the positions of the available tokens and the value of the synchronization
point serial
number, which will be the next synchronization point serial number to be used.
.PP
The service may be initiated by either SS\(hyuser and has the
following characteristics:
.RT
.LP
a)
after issuing the S\(hyRESYNCHRONIZE request, the requestor is
not able to initiate any services except S\(hyU\(hyABORT request,
until the S\(hyRESYNCHRONIZE confirm is received;
.LP
b)
after having received an S\(hyRESYNCHRONIZE indication, the
acceptor may only issue:
.LP
1)
S\(hyRESYNCHRONIZE response; or
.LP
2)
S\(hyRESYNCHRONIZE request (see note); or
.LP
3)
S\(hyACTIVITY\(hyDISCARD request (see note); or
.LP
4)
S\(hyACTIVITY\(hyINTERRUPT request (see note); or
.LP
5)
S\(hyU\(hyABORT request.
.LP
\fINote\fR \ \(em\ These requests cause a collision of
resynchronize requests and therefore the SS\(hyuser can only issue the
request if he is going to be the collision winner (see \(sc\ 16).
.LP
c)
all undelivered data are purged;
.LP
d)
means are provided for the requesting SS\(hyuser either to set or to
let the acceptor set a new assignment of each available
token;
.LP
e)
means are provided to assign a new value for the
synchronization point serial number;
.LP
f
)
when there is an unacknowledged major synchronization point at the time
of the S\(hyRESYN
CHRONIZE indication, this point
remains unacknowledged. In any case, no confirmations should
be issued until the resynchronization is complete and until new
indications for synchronization points have been received;
.LP
g)
collision of resynchronize requests is resolved, so that
only one of the colliding requests is confirmed
(see \(sc\ 16).
.PP
The Resynchronize Type parameter is used to indicate the
resynchronize option:
.LP
h)
\fIabandon\fR \| is used to request the SS\(hyprovider
to resynchronize the session connection to a new synchronization
point which is greater than or equal to V(M). The new
synchronization point serial number will be greater than any
previous value used on this session connection. Where there are
unacknowledged minor synchronization points at the time of the
S\(hyRESYNCHRONIZE request/indication, they remain
unacknowledged;
.LP
i)
\fIrestart\fR \| is used to return to an agreed point which is
identified by a past acknowledged synchronization point serial
number. This point cannot be earlier than the last confirmed
major synchronization point. The necessary securing of state
information associated with the point is the responsability
of the SS\(hyusers;
.LP
j
)
\fIset\fR \| is used to synchronize to any valid
synchronization point serial number specified by the SS\(hyusers. When
there are unacknowledged minor synchronization points at the time
of the S\(hyRESYN
CHRONIZE request/indication, they remain
unacknowledged.
.sp 1P
.LP
13.10.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 19/X.215 specifies the types of session service primitives
and parameters needed for the resynchronize service.
.bp
.RT
.ce
\fBH.T. [T19.215]\fR
.ce
TABLE\ 19/X.215
.ce
\fBResynchronize primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 19/X.215 [T19.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.10.2.1\ \ \fIResynchronize Type\fR \| is a parameter which specifies
one of the resynchronize options. Its value is one of:
.sp 9p
.RT
.LP
a)
abandon;
.LP
b)
restart;
.LP
c)
set.
.sp 1P
.LP
13.10.2.2\ \ \fISynchronization Point Serial Number\fR \| depends on the
resynchronize option and is defined in \(sc\(sc\ 11.4 and\ 11.4.5.
.sp 9p
.RT
.sp 1P
.LP
13.10.2.3\ \ Assignment of
\fITokens\fR \| is a list of the available tokens for the session connection
with values for their assignment following the
resynchronization. For each available token, the value in a request/indication
is one of:
.sp 9p
.RT
.LP
a)
requestor side;
.LP
b)
acceptor side;
.LP
c)
acceptor chooses.
.PP
The value for a response/confirm is the same as in the
request/indication unless that value is c), in which case the acceptor
chooses a) or\ b).
.sp 1P
.LP
13.10.2.4\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.10.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful resynchronization
without collision is defined by the time sequence diagram shown in
Figure\ 15/X.215. Collision cases are defined in \(sc\ 16.
.RT
.LP
.rs
.sp 8P
.ad r
\fBFigure 15/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.11
\fIP\(hyexception reporting service\fR
.sp 1P
.RT
.sp 1P
.LP
13.11.1
\fIFunction\fR
.sp 9p
.RT
.PP
The P\(hyexception reporting service permits SS\(hyusers to be notified
of unanticipated situations not covered by other services. If a service
cannot be completed due to SS\(hyprovider protocol errors or malfunctions,
the
P\(hyexception reporting service is used to indicate this to both SS\(hyusers.
.PP
If used with the activity management service, the P\(hyexception
reporting service is only permitted while an activity is in progress or
waiting for S\(hyCAPABILITY\(hyDATA confirm.
.PP
Following an S\(hyP\(hyEXCEPTION\(hyREPORT indication, and until the error
condition is cleared:
.RT
.LP
a)
NSSDUs, TSSDUs and XSSDUs will be discarded by the
SS\(hyprovider;
.LP
b)
synchronization point indications will not be given to the SS\(hyusers.
.PP
On receipt of an S\(hyP\(hyEXCEPTION\(hyREPORT indication, either SS\(hyuser
initiates one of the following services to clear the error:
.LP
c)
resynchronize;
.LP
d)
abort;
.LP
e)
activity interrupt or activity discard;
.LP
f
)
give the data token (see notes).
.PP
The SS\(hyusers are not permitted to initiate any other services
until the error is cleared.
.PP
\fINote\ 1\fR \ \(em\ It is not recommended that the error condition be
cleared by passing the data token when the resynchronize and/or activity
management
functional units have been selected.
.PP
\fINote\ 2\fR \ \(em\ If the error condition is cleared by passing the data
token, data and synchronization point serial numbers may be lost. However,
the SS\(hyprovider will keep track of the serial numbers of the synchronization
points which have been discarded. Therefore, the synchronization point
serial number indicated to the SS\(hyuser in a synchronization point request/indication
made
after the error condition has been cleared will reflect the fact that
synchronization points have been discarded during the error condition.
.PP
\fINote\ 3\fR \ \(em\ XSSDUs sent after the S\(hyTOKEN\(hyGIVE request will be
discarded if they overtake the request.
.PP
\fINote\ 4\fR \ \(em\ Tokens other than the data token may be transferred
at the same time.
.RT
.sp 1P
.LP
13.11.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 20/X.215 specifies the types of session service primitives
and parameters needed for the P\(hyexception reporting service.
.RT
.ce
\fBH.T. [T20.215]\fR
.ce
TABLE\ 20/X.215
.ce
\fBP\(hyexception reporting primitives and parameters\fR
.T&
lw(84p) | lw(84p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 20/X.215 [T20.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
\fIReason\fR \| is a parameter specifying the reason for the exception
report. Its value is one of:
.LP
a)
protocol error;
.LP
b)
non\(hyspecific error.
.sp 1P
.LP
13.11.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful P\(hyexception report is
defined by the time sequence diagram shown in Figure 16/X.215.
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 16/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.12
\fIU\(hyexception reporting service\fR
.sp 1P
.RT
.sp 1P
.LP
13.12.1
\fIFunction\fR
.sp 9p
.RT
.PP
The U\(hyexception reporting service permits an SS\(hyuser to report an
exception condition subject to the token restrictions specified in
Table\ 8/X.215.
.PP
If used with the activity management service, the U\(hyexception
reporting service is only permitted while an activity is in progress.
.PP
Following an S\(hyU\(hyEXCEPTION\(hyREPORT request, and until the error
condition is cleared:
.RT
.LP
a)
NSSDUs, TSSDUs and XSSDUs will be discarded by the
SS\(hyprovider;
.LP
b)
synchronization point indications will not be given to the requestor
of the S\(hyU\(hyEXCEPTION\(hyREPORT;
.LP
c)
the requestor is only permitted to issue S\(hyU\(hyABORT
request.
.PP
On receipt of an S\(hyU\(hyEXCEPTION\(hyREPORT indication, the acceptor
initiates one of the following services to clear the error:
.LP
d)
resynchronize;
.LP
e)
abort;
.LP
f
)
activity interrupt or activity discard;
.LP
g)
give the data token (see notes).
.PP
The acceptor is not permitted to initiate any other services until the
error is cleared.
.PP
\fINote\ 1\fR \ \(em\ It is not recommended that the error condition be
cleared by passing the data token when the resynchronize and/or activity
management
functional units have been selected.
.PP
\fINote\ 2\fR \ \(em\ If the error condition is cleared by passing the data
token, data and synchronization point serial numbers may be lost. However,
the SS\(hyprovider will keep track of the serial numbers of the synchronization
points which have been discarded. Therefore, the synchronization point
serial number indicated to the SS\(hyuser in a synchronization point request/indication
made
after the error condition has been cleared will reflect the fact that
synchronization points have been discarded during the error condition.
.PP
\fINote\ 3\fR \ \(em\ XSSDUs sent after the S\(hyTOKEN\(hyGIVE request will be
discarded if they overtake the request.
.PP
\fINote\ 4\fR \ \(em\ Tokens other than the data token may be transferred
at the same time.
.bp
.RT
.sp 1P
.LP
13.12.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 21/X.215 specifies the types of session service primitives
and parameters needed for the U\(hyexception reporting service.
.RT
.ce
\fBH.T. [T21.215]\fR
.ce
TABLE\ 21/X.215
.ce
\fBU\(hyexception reporting primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 21/X.215 [T21.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.12.2.1\ \ \fIReason\fR \| is a parameter specifying the reason for the
exception report and is transparent to the SS\(hyprovider. Its value is
one of:
.sp 9p
.RT
.LP
a)
SS\(hyuser receiving ability jeopardized (i.e. data received
may not be handled correctly);
.LP
b)
local SS\(hyuser error;
.LP
c)
sequence error;
.LP
d)
demand data token;
.LP
e)
unrecoverable procedural error;
.LP
f
)
non\(hyspecific error.
.sp 1P
.LP
13.12.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.12.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful U\(hyexception report is
defined by the time sequence diagram shown in Figure 17/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 17/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.13
\fIActivity start service\fR
.sp 1P
.RT
.sp 1P
.LP
13.13.1
\fIFunction\fR
.sp 9p
.RT
.PP
The activity start service allows an SS\(hyuser to indicate that a
new activity is entered. The value of the next synchronization point serial
number to be used is set to one (see \(sc\ 11.4.6). The service can only be
initiated if no activity is in progress and subject to the token restrictions
specified in Table\ 8/X.215.
.RT
.sp 1P
.LP
13.13.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 22/X.215 specifies the types of session service primitives
and parameters needed for the activity start service.
.RT
.ce
\fBH.T. [T22.215]\fR
.ce
TABLE\ 22/X.215
.ce
\fBActivity start primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 22/X.215 [T22.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.13.2.1\ \ \fIActivity identifier\fR \| is a parameter which is provided
by the
SS\(hyusers to enable them to identify the new activity and is transparent
to the SS\(hyprovider. This parameter has a maximum of 6\ octets.
.sp 9p
.RT
.sp 1P
.LP
13.13.2.2\ \
\fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.13.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful activity start is
defined by the time sequence diagram shown in Figure\ 18/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 18/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.14
\fIActivity resume service\fR
.sp 1P
.RT
.sp 1P
.LP
13.14.1
\fIFunction\fR
.sp 9p
.RT
.PP
The activity resume service allows an SS\(hyuser to indicate that a
previously interrupted activity is resumed. A new activity identifier is
provided by the SS\(hyuser together with the identifier of the activity being
resumed and the next synchronization point serial number to be used minus
one. In the case when the resumed activity was originally started on another
session connection, the session connection identifier of that session connection
is
also provided by the SS\(hyuser.
.PP
The service can only be initiated if no activity is in progress and
subject to the token restrictions specified in Table\ 8/X.215.
.RT
.sp 1P
.LP
13.14.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 23/X.215 specifies the types of session service primitives
and parameters needed for the activity resume.
.RT
.ce
\fBH.T. [T23.215]\fR
.ce
TABLE\ 23/X.215
.ce
\fBActivity resume primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 23/X.215 [T23.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.14.2.1\ \
\fIActivity Identifier\fR \| is a parameter which is provided by the SS\(hyusers
to enable them to give a new identifier to the activity being resumed and
is transparent to the SS\(hyprovider. This parameter has a maximum of 6\
octets.
.sp 9p
.RT
.sp 1P
.LP
13.14.2.2\ \
\fIOld Activity Identifier\fR \| is the original identifier
of the activity being resumed and is transparent to the SS\(hyprovider.
.sp 9p
.RT
.sp 1P
.LP
13.14.2.3\ \
\fISynchronization Point Serial Number\fR \| is provided by
the SS\(hyuser and is defined in \(sc\ 11.4.6.
.sp 9p
.RT
.sp 1P
.LP
13.14.2.4\ \
\fIOld Session Connection Identifier\fR \| is the session
connection identifier of the session connection in which the activity being
resumed was originally started and is transparent to the SS\(hyprovider. It
consists of:
.sp 9p
.RT
.LP
a)
Calling SS\(hyuser Reference with a maximum of 64 octets;
.LP
b)
Called SS\(hyuser Reference with a maximum of 64 octets;
.LP
c)
Common Reference with a maximum of 64\ octets;
.LP
d)
Additional Reference Information with a maximum of
4\ octets.
.sp 1P
.LP
13.14.2.5\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.bp
.sp 9p
.RT
.sp 1P
.LP
13.14.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful activity resume is
defined by the time sequence diagram shown in Figure 19/X.215.
.RT
.LP
.rs
.sp 8P
.ad r
\fBFigure 19/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.15
\fIActivity interrupt service\fR
.sp 1P
.RT
.sp 1P
.LP
13.15.1
\fIFunction\fR
.sp 9p
.RT
.PP
The activity interrupt service allows an SS\(hyuser to abnormally
terminate the current activity so that work achieved before the interruption
is not cancelled, and may be resumed later.
.PP
The service can only be initiated if an activity is in progress and
subject to the token restrictions specified in Table\ 8/X.215. After receipt
of the confirm, all available tokens are assigned to the SS\(hyuser which
issued the request.
.PP
After issuing an S\(hyACTIVITY\(hyINTERRUPT request, the requestor is not
able to initiate any services, except S\(hyU\(hyABORT request, until the
S\(hyACTIVITY\(hyINTERRUPT confirm is received.
.PP
After receiving an S\(hyACTIVITY\(hyINTERRUPT indication, the acceptor is
not able to initiate any services, except S\(hyU\(hyABORT request, until the
S\(hyACTIVITY\(hyINTERRUPT response is issued.
.PP
Use of this service may cause loss of data which has not yet been
delivered to the SS\(hyuser.
.RT
.sp 1P
.LP
13.15.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 24/X.215 specifies the types of session service primitives
and parameters needed for the activity interrupt service.
.RT
.ce
\fBH.T. [T24.215]\fR
.ce
TABLE\ 24/X.215
.ce
\fBActivity interrupt primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
T{
SS\(hyuser data
U
C(=)
U
C(=)
C:
presence of the parameter is conditional.
.line
U:
presence of the parameter is a user option.
.line
Blank:
the parameter is absent.
.line
(=):
the value of the parameter is identical to the value of the
corresponding parameter of the preceding SS primitive.
.parag
T}
.TE
.nr PS 9
.RT
.ad r
\fBTable 24/X.215 [T24.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
13.15.2.1\ \ \fIReason\fR \| is a parameter specifying the reason for the
activity interrupt and is transparent to the SS\(hyprovider. Its value
is one of:
.sp 9p
.RT
.LP
a)
SS\(hyuser receiving ability jeopardized (i.e. data received
may not be handled correctly);
.LP
b)
local SS\(hyuser error;
.LP
c)
sequence error;
.LP
d)
demand data token;
.LP
e)
unrecoverable procedural error;
.LP
f
)
non\(hyspecific error.
.sp 1P
.LP
13.15.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.15.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful activity interrupt is
defined by the time sequence diagram shown in Figure\ 20/X.215.
.RT
.LP
.rs
.sp 15P
.ad r
\fBFigure 20/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
13.16
\fIActivity discard service\fR
.sp 1P
.RT
.sp 1P
.LP
13.16.1
\fIFunction\fR
.sp 9p
.RT
.PP
The activity discard service allows an SS\(hyuser to abnormally
terminate the current activity. There is an implied meaning to the SS\(hyuser
that the previous content of this activity is cancelled, but this is not
controlled by the SS\(hyprovider.
.PP
The service can only be initiated if an activity is in progress and
subject to the token restrictions specified in Table\ 8/X.215. After receipt
of the confirm, all available tokens are assigned to the SS\(hyuser which
issued the request.
.PP
After issuing an S\(hyACTIVITY\(hyDISCARD request, the requestor is not
able to initiate any services, except S\(hyU\(hyABORT request, until the
S\(hyACTIVITY\(hyDISCARD confirm is received.
.PP
After receiving an S\(hyACTIVITY\(hyDISCARD indication, the acceptor is
not able to initiate any services, except S\(hyU\(hyABORT request, until
the
S\(hyACTIVITY\(hyDISCARD response is issued.
.PP
Use of this service may cause loss of data which has not yet been
delivered to the SS\(hyuser.
.bp
.RT
.sp 1P
.LP
13.16.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 25/X.215 specifies the types of session service primitives
and parameters needed for the activity discard service.
.RT
.ce
\fBH.T. [T25.215]\fR
.ce
TABLE\ 25/X.215
.ce
\fBActivity discard primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
T{
SS\(hyuser data
U
C(=)
U
C(=)
C:
presence of the parameter is conditional.
.line
U:
presence of the parameter is a user option.
.line
Blank:
the parameter is absent.
.line
(=):
the value of the parameter is identical to the value of the
corresponding parameter of the preceding SS primitive.
.parag
T}
.TE
.nr PS 9
.RT
.ad r
\fBTable 25/X.215 [T25.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.16.2.1\ \ \fIReason\fR \| is a parameter specifying the reason for the
activity discard and is transparent to the SS\(hyprovider. Its value is
one of:
.sp 9p
.RT
.LP
a)
SS\(hyuser receiving ability jeopardized (i.e. data received
may not be handled correctly);
.LP
b)
local SS\(hyuser error;
.LP
c)
sequence error;
.LP
d)
demand data token;
.LP
e)
unrecoverable procedural error;
.LP
f
)
non\(hyspecific error.
.sp 1P
.LP
13.16.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
13.16.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful activity discard is
defined by the time sequence diagram shown in Figure\ 21/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 21/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
13.17
\fIActivity end service\fR
.sp 1P
.RT
.sp 1P
.LP
13.17.1
\fIFunction\fR
.sp 9p
.RT
.PP
The activity end service allows an SS\(hyuser to indicate the end of an
activity, and has the effect of setting a major synchronization point.
This service can only be invoked if an activity is in progress and subject
to the
token restrictions specified in Table\ 8/X.215.
.PP
After issuing the S\(hyACTIVITY\(hyEND request, in addition to any existing
restrictions, the requestor is not able to initiate any services, except
for
S\(hyU\(hyABORT request, S\(hyACTIVITY\(hyINTERRUPT request, S\(hyACTIVITY\(hyDISCARD
request or S\(hyTOKEN\(hyGIVE request until the S\(hyACTIVITY\(hyEND confirm
is received.
.PP
After receiving the S\(hyACTIVITY\(hyEND indication, in addition to any
existing restrictions, the acceptor is not able to initiate S\(hySYNC\(hyMAJOR
request, S\(hySYNC\(hyMINOR request, S\(hyACTIVITY\(hyINTERRUPT request,
S\(hyACTIVITY\(hyDISCARD request, S\(hyACTIVITY\(hyEND request or S\(hyRELEASE
request until the S\(hyACTIVITY\(hyEND response is issued.
.PP
If the activity management functional unit has been selected, the
SS\(hyuser is not allowed to initiate any services, except activity start,
activity resume, token management, capability data, expedited data, typed
data, normal data, release or abort, until an activity is started or
resumed.
.RT
.sp 1P
.LP
13.17.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 26/X.215 specifies the types of session service primitives
and parameters needed for the activity end service.
.RT
.ce
\fBH.T. [T26.215]\fR
.ce
TABLE\ 26/X.215
.ce
\fBActivity end primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 26/X.215 [T26.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
13.17.2.1\ \ \fISynchronization Point Serial Number\fR \| is defined in
\(sc\ 11.4.6.
.sp 9p
.RT
.sp 1P
.LP
13.17.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.bp
.sp 9p
.RT
.sp 1P
.LP
13.17.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful normal termination of an activity
is defined by the time sequence diagram shown in
Figure\ 22/X.215.
.RT
.LP
.rs
.sp 9P
.ad r
\fBFigure 22/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
\fB14\fR \fBSession connection release phase\fR
.sp 1P
.RT
.sp 2P
.LP
14.1
\fIOrderly release service\fR
.sp 1P
.RT
.sp 1P
.LP
14.1.1
\fIFunction\fR
.sp 9p
.RT
.PP
The orderly release service is always provided and allows either
SS\(hyuser to release the session connection in an orderly manner. This is done
cooperatively between the two SS\(hyusers without the loss of data after all
in\(hytransit data have been delivered and accepted by both SS\(hyusers.
.PP
Use of this service is subject to the token restrictions specified
in Table\ 8/X.215. If the release token is available, the acceptor may
refuse the release and continue the session connection without loss of data.
If the release token is not available, the acceptor cannot refuse the
release.
.RT
.sp 1P
.LP
14.1.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 27/X.215 specifies the types of session service primitives
and parameters needed for the orderly release service.
.RT
.ce
\fBH.T. [T27.215]\fR
.ce
TABLE\ 27/X.215
.ce
\fBOrderly release primitives and parameters\fR
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
.T&
lw(84p) | lw(36p) | lw(36p) | lw(36p) | lw(36p) .
T{
M
M(=)
SS\(hyuser data
U
C(=)
U
C(=)
M:
presence of the parameter is mandatory.
.line
C:
presence of the parameter is conditional.
.line
U:
presence of the parameter is a user option.
.line
Blank:
the parameter is absent.
.line
(=):
the value of the parameter is identical to the value of the
corresponding parameter of the preceding SS primitive.
.parag
T}
.TE
.nr PS 9
.RT
.ad r
\fBTable 27/X.215 [T27.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
14.1.2.1\ \ \fIResult\fR \| is a parameter indicating whether or not the
session
release is granted. Its value may be one of:
.sp 9p
.RT
.LP
a)
affirmative;
.LP
b)
negative.
.PP
The latter value may be given only if the release token is
available.
.sp 1P
.LP
14.1.2.2\ \ \fISS\(hyuser data\fR \| is a parameter containing an unlimited
number of octets of user information.
.sp 9p
.RT
.sp 1P
.LP
14.1.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful orderly session release is defined
by the time sequence diagram shown in Figure\ 23/X.215.
.RT
.LP
.rs
.sp 8P
.ad r
\fBFigure 23/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
A collision of S\(hyRELEASE requests may occur when no tokens are
available. This results in S\(hyRELEASE indications to both SS\(hyuser.
In this case, the calling SS\(hyuser should send the S\(hyRELEASE response
after receiving the
S\(hyRELEASE indication from the called SS\(hyuser. The called SS\(hyuser
should not
send his S\(hyRELEASE response before receiving the S\(hyRELEASE confirm
from the
calling SS\(hyuser.
.sp 2P
.LP
14.2
\fIU\(hyabort service\fR
.sp 1P
.RT
.sp 1P
.LP
14.2.1
\fIFunction\fR
.sp 9p
.RT
.PP
The U\(hyabort service provides the means by which either SS\(hyuser can
instantaneously release the session connection and have the other SS\(hyuser
informed of this release. Use of this service will cause loss of undelivered
data.
.RT
.sp 1P
.LP
14.2.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 28/X.215 specifies the types of session service primitives
and parameters needed for the U\(hyabort service.
.RT
.ce
\fBH.T. [T28.215]\fR
.ce
TABLE\ 28/X.215
.ce
\fBU\(hyabort primitives and parameters\fR
.T&
lw(84p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 28/X.215 [T28.215], p. \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
\fISS\(hyuser data\fR \| is a parameter containing an unlimited number
of octets of user information.
.sp 1P
.LP
14.2.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful U\(hyabort is defined by
the time sequence diagram shown in Figure\ 24/X.215.
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 24/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
14.3
\fIP\(hyabort service\fR
.sp 1P
.RT
.sp 1P
.LP
14.3.1
\fIFunction\fR
.sp 9p
.RT
.PP
The P\(hyabort service provides the means by which the SS\(hyprovider may
indicate the release of the session connection for reasons internal to
the
SS\(hyprovider. Use of this service will cause loss of undelivered data.
A reason code of limited size is passed from the SS\(hyprovider to the
SS\(hyuser.
.RT
.sp 1P
.LP
14.3.2
\fITypes of primitives and their parameters\fR
.sp 9p
.RT
.PP
Table 29/X.215 specifies the types of session service primitives
and parameters needed for the P\(hyabort service.
.RT
.LP
.sp 2
.ce
\fBH.T. [T29.215]\fR
.ce
TABLE\ 29/X.215
.ce
\fBP\(hyabort primitives and parameters\fR
.T&
lw(84p) | lw(84p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 29/X.215 [T29.215], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
\fIReason\fR \| is a parameter indicating the reason for the abort. Its
value is one of:
.LP
a)
transport disconnect;
.LP
b)
protocol error;
.LP
c)
undefined;
.LP
d)
implementation restriction stated in the PICS.
.sp 1P
.LP
14.3.3
\fISequence of primitives\fR
.sp 9p
.RT
.PP
The sequence of primitives in a successful P\(hyabort is defined by
the time sequence diagram shown in Figure\ 25/X.215.
.RT
.LP
.rs
.sp 12P
.ad r
\fBFigure 25/X.215, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB15\fR \fBSequences of primitives\fR
.sp 1P
.RT
.sp 1P
.LP
15.1
\fIState tables\fR
.sp 9p
.RT
.PP
Annex A contains state tables which define the constraints on the sequences
in which the session service primitives may occur. The constraints
determine the order in which the session services occur, but do not fully
specify when they may occur. Other constraints will affect the ability of an
SS\(hyuser or the SS\(hyprovider to issue a primitive at any particular
time.
.RT
.sp 1P
.LP
15.2
\fISequences of primitives at one session connection end\(hypoint\fR
.sp 9p
.RT
.PP
The possible sequences of primitives at one session connection
end\(hypoint may be derived directly from the state tables in
Annex\ A.
.RT
.sp 2P
.LP
\fB16\fR \fBCollision\fR
.sp 1P
.RT
.sp 1P
.LP
16.1
\fICollision as viewed by the SS\(hyuser\fR
.sp 9p
.RT
.PP
The SS\(hyprovider resolves collisions between those requests that may
destroy SS\(hyuser data. If a collision occurs, one of the SS\(hyusers
will receive an unexpected indication while awaiting one of the following:
.RT
.LP
a)
S\(hyRESYNCHRONIZE confirm;
.LP
b)
S\(hyACTIVITY\(hyINTERRUPT confirm;
.LP
c)
S\(hyACTIVITY\(hyDISCARD confirm;
.LP
d)
clearing the error state after issuing an
S\(hyEXCEPTION\(hyREPORT request.
.PP
Table 30/X.215 defines the indications that may be received which indicate
that the SS\(hyuser has lost a collision resolved by the
SS\(hyprovider.
.bp
.ce
\fBH.T. [T30.215]\fR
.ce
TABLE\ 30/X.215
.ce
\fBIndications resulting from collision resolution\fR
.T&
lw(144p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) |
lw(12p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable 30/X.215 [T30.215], p. \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
16.2
\fICollision resolution by the SS\(hyprovider\fR
.sp 9p
.RT
.PP
The SS\(hyprovider resolves colliding SS\(hyuser requests according to
the following rules.
.PP
In the case of collision between two of the following types of
requests, the first in the list takes precedence.
.RT
.LP
a)
S\(hyU\(hyABORT request;
.LP
b)
S\(hyACTIVITY\(hyDISCARD request;
.LP
c)
S\(hyACTIVITY\(hyINTERRUPT request;
.LP
d)
S\(hyRESYNCHRONIZE (abandon) request;
.LP
e)
S\(hyRESYNCHRONIZE (set) request;
.LP
f
)
S\(hyRESYNCHRONIZE (restart) request;
.LP
g)
S\(hyU\(hyEXCEPTION\(hyREPORT request.
.PP
Possible collisions of the same request are handled as
follows:
.LP
h)
If two S\(hyRESYNCHRONIZE (abandon) requests collide, the
calling SS\(hyuser request takes precedence.
.LP
i)
If two S\(hyRESYNCHRONIZE (restart) requests collide, the
request with the lowest serial number takes precedence.
If the serial numbers are equal, the calling SS\(hyuser
request takes precedence.
.LP
j
)
If two S\(hyRESYNCHRONIZE (set) requests collide, the
calling SS\(hyuser request takes precedence.
.bp
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation X.215)
.sp 9p
.RT
.ce 0
.ce 1000
\fBState tables\fR
.sp 1P
.RT
.ce 0
.LP
A.1
\fIGeneral\fR
.sp 1P
.RT
.PP
This Annex describes the session service in terms of state tables. The
state tables show the state of an SS\(hyuser, the events that occur at
the
session service boundary, the actions taken by the SS\(hyuser and the resultant
state.
.PP
These state tables do not constitute a formal definition of the
session service; they are included to provide a more precise definition
of the relationships between session service primitives defined in \(sc\(sc\
12, 13 and\ 14.
.PP
Table\ A\(hy1/X.215 specifies the abbreviated name and name of each
incoming event generated by the SS\(hyprovider.
.PP
Table A\(hy2/X.215 specifies the abbreviated name and name of each
state.
.PP
Table A\(hy3/X.215 specifies the abbreviated name and name of each
outgoing event generated by the SS\(hyuser.
.PP
Table A\(hy4/X.215 summarizes the operations on the variables V(A), V(M),
V(R) and Vsc.
.PP
Table A\(hy5/X.215 specifies the specific actions.
.PP
Table A\(hy6/X.215 specifies the predicates.
.PP
Tables A\(hy7/X.215 to 14/X.215 specify the state tables.
.RT
.sp 2P
.LP
A.2
\fINotation for state tables\fR
.sp 1P
.RT
.PP
A.2.1
Incoming events, states and outgoing events are represented
by their abbreviated names.
.sp 9p
.RT
.PP
A.2.2
Specific actions are represented by the notation (n), where n is the number
of the specific action in Table\ A\(hy5/X.215.
.PP
A.2.3
Predicates are represented by the notation pn, where n is the
number of the predicate in Table\ A\(hy6/X.215.
.PP
A.2.4
Boolean operators are represented by the following
notation:
.LP
&
AND
.LP
\*\|o
NOT
.LP
OR
OR
.sp 2P
.LP
A.3
\fIConventions for entries in state tables\fR
.sp 1P
.RT
.PP
A.3.1
The intersection of each state and incoming or outgoing event which is
invalid is left blank.
.sp 9p
.RT
.PP
A.3.2
The intersection of each state and incoming or outgoing event
which is valid contains entries which are either:
.LP
a)
an \fIaction list\fR which:
.LP
1)
may contain specific actions;
.LP
2)
always contains the resultant state; or
.LP
b)
one or more \fIconditional action lists\fR , each consisting
of:
.LP
1)
a predicate expression comprising predicates and
boolean operators;
.LP
2)
an action list [as in \(sc\ A.3.2\|a)].
.LP
\fINote\fR \ \(em\ The action lists and conditional action lists use the
notation in \(sc\ A.2.
.sp 1P
.LP
A.4
\fIActions to be taken by the SS\(hyuser\fR
.sp 9p
.RT
.PP
The state tables define the action to be taken by the
SS\(hyuser.
.RT
.sp 1P
.LP
A.4.1
\fIInvalid intersections\fR
.sp 9p
.RT
.PP
If the intersection of the state and an incoming or outgoing event is invalid,
any action taken by the SS\(hyuser is a local matter.
.bp
.RT
.sp 1P
.LP
A.4.2
\fIValid intersections\fR
.sp 9p
.RT
.PP
If the intersection of the state and incoming event is valid, one of the
following actions shall be taken.
.RT
.PP
A.4.2.1
If the intersection contains an action list, the SS\(hyuser shall
take the specific actions in the order specified in the state table.
.PP
A.4.2.2
If the intersection contains one or more conditional action
lists, for each predicate expression that is true, the SS\(hyuser shall
take the specific actions in the order given in the action list associated
with the
predicate expression. If none of the predicate expressions are true, the
SS\(hyuser shall take one of the actions defined in \(sc\ A.4.1.
.sp 1P
.LP
A.5
\fIDefinitions of sets and variables\fR
.sp 9p
.RT
.PP
The following sets and variables are specified in this
Recommendation.
.RT
.sp 1P
.LP
A.5.1
\fIFunctional units\fR
.sp 9p
.RT
.PP
The set of all functional units specified in this Recommendation is defined as:
.RT
.LP
fu\(hydom\ =\ {FD, HD, EXCEP, TD, NR, SY, MA, RESYN, EX, ACT, CD}
.LP
where:
.LP
FD
=\ Duplex functional unit
.LP
HD
=\ Half\(hyduplex functional unit
.LP
EXCEP
=\ Exceptions functional unit
.LP
TD
=\ Typed data functional unit
.LP
NR
=\ Negotiated release functional unit
.LP
SY
=\ Minor synchronize functional unit
.LP
MA
=\ Major synchronize functional unit
.LP
RESYN
=\ Resynchronize functional unit
.LP
EX
=\ Expedited data functional unit
.LP
ACT
=\ Activity management functional unit
.LP
CD
=\ Capability data exchange functional unit
.PP
A boolean function FU is defined over fu\(hydom as follows:
.LP
for f in fu\(hydom
.LP
FU(f)\ =\ true:
if and only if the functional unit f has been
selected during the session connection
establishment phase.
.PP
The value is set when the S\(hyCONNECT response is issued or the
S\(hyCONNECT confirm is received.
.sp 1P
.LP
A.5.2
\fITokens\fR
.sp 9p
.RT
.PP
The set of all tokens specified in this Recommendation is defined as:
.RT
.LP
tk\(hydom = {mi, ma, tr, dk}
.LP
where:
.LP
mi
=\ synchronize\(hyminor token
.LP
ma
=\ major/activity token
.LP
tr
=\ release token
.LP
dk
=\ data token
.PP
The following boolean functions are defined over tk\(hydom:
.LP
a)
AV(t), for t in tk\(hydom, is a function which defines the
availability of the corresponding token and has the
following values:
.LP
AV(mi)
=\ FU(SY)
.LP
AV(dk)
=\ FU(HD)
.LP
AV(tr)
=\ FU(NR)
.LP
AV(ma)
=\ FU(MA) or FU(ACT)
.bp
.LP
b)
OWNED(t), for t in tk\(hydom, is a function which defines the
assignment of the corresponding token and is defined
as:
.LP
OWNED(t)\ =\ true:
if token assigned to the
SS\(hyuser;
.LP
OWNED(t)\ =\ false:
if token not assigned to the
SS\(hyuser.
.LP
OWNED(t) is not defined if AV(t) = false.
.LP
OWNED(t) is set when:
.LP
1)
the S\(hyCONNECT response is issued or the S\(hyCONNECT
confirm is received; or
.LP
2)
the S\(hyRESYNCHRONIZE response is issued or the
S\(hyRESYNCHRONIZE confirm is received; or
.LP
3)
the S\(hyTOKEN\(hyGIVE request is issued or the S\(hyTOKEN\(hyGIVE
indication is received; or
.LP
4)
the S\(hyCONTROL\(hyGIVE request is issued or the
S\(hyCONTROL\(hyGIVE indication is received;
.LP
5)
the S\(hyACTIVITY\(hyINTERRUPT response is issued or the
S\(hyACTIVITY\(hyINTERRUPT confirm is received;
.LP
6)
the S\(hyACTIVITY\(hyDISCARD response is issued or the
S\(hyACTIVITY\(hyDISCARD confirm is received.
.LP
c)
I(t), for t in tk\(hydom, is a function which, when true,
indicates that the SS\(hyuser has \fII\fR nitiating rights for the
behaviour controlled by the token. This applies even if the
corresponding token is not available:
.LP
I(t)\ =\ \*\|iAV(t) OR OWNED(t)
.LP
d)
A(t), for t in tk\(hydom, is a function which, when true,
indicates that the SS\(hyuser has \fIA\fR ccepting rights for the
behaviour controlled by the token. This applies even if the
corresponding token is not available:
.LP
A(t)\ =\ \*\|iAV(t) OR \*\|iOWNED(t)
.LP
e)
II(t), for t in tk\(hydom, is a function which, when true,
indicates that the SS\(hyuser has \fII\fR nitiating rights as
I(t), but this applies to the case when the behaviour may
only be initiated if the corresponding token is available
and owned:
.LP
II(t)\ =\ AV(t) AND OWNED(t)
.LP
f
)
AA(t), for t in tk\(hydom, is a function which, when
true, indicates that the SS\(hyuser has \fIA\fR ccepting rights as
A(t), but only if the corresponding token is available but
not owned:
.LP
AA(t)\ =\ AV(t) AND \*\|iOWNED(t)
.sp 1P
.LP
A.5.3
\fISET of tokens\fR
.sp 9p
.RT
.PP
The following subsets of tk\(hydom are defined:
.RT
.LP
RT
=\ {tokens requested in the input event}
.LP
GT
=\ {tokens given in the input event}
.PP
For the purpose of the following function definitions, two further sets
are defined:
.LP
F
=\ {AV, OWNED, I, A, II, AA} (the set of functions defined in \(sc\ A.5.2)
.LP
S
=\ the set of subsets of tk\(hydom
.PP
The following functions are defined over F and S:
.LP
a)
ALL(f,\ s), for f in F and s in S:
.LP
ALL(f,\ s)\ =\ true:
all of the f(t) for t in s are true
or s is empty;
.LP
For example:
.LP
ALL(A,\ tk\(hydom)\ =\ true:
none of the available tokens are
owned (e.g. on receipt of a
S\(hyRELEASE indication)
.LP
b)
ANY(f,\ s), for f in F and s in S:
.LP
ANY(f,\ s)\ =\ true:
any f(t) = true for t in s and s is
not empty;
.LP
For example:
.LP
ANY(II,\ tk\(hydom)\ =\ true:
at least one of the available
tokens is owned.
.bp
.sp 2P
.LP
A.5.4
\fIVariables\fR
.sp 1P
.RT
.sp 1P
.LP
A.5.4.1
\fIVact\fR
.sp 9p
.RT
.PP
Vact is a boolean variable having the following values when the
activity management functional unit has been selected (FU(ACT) = true):
.RT
.LP
Vact\ =\ true:\ an activity is in progress;
.LP
Vact\ =\ false:\ no activity is in progress;
.LP
Vact has no defined value if FU(ACT) = false.
.PP
Vact is set as follows:
.LP
a)
Vact is set false during the connection establishment phase,
if the activity management functional unit has been selected
(FU(ACT) = true). Otherwise, Vact is not set.
.LP
b)
Vact is set true when the S\(hyACTIVITY\(hySTART request or
S\(hyACTIVITY\(hyRESUME request is issued or the S\(hyACTIVITY\(hySTART
indication or S\(hyACTIVITY\(hyRESUME indication is received
(only possible when FU(ACT) = true).
.LP
c)
Vact is set false when the S\(hyACTIVITY\(hyDISCARD response or
S\(hyACTIVITY\(hyINTERRUPT response is issued or the
S\(hyACTIVITY\(hyDISCARD confirm or S\(hyACTIVITY\(hyINTERRUPT confirm
is received.
.LP
d)
Vact is set false when the S\(hyACTIVITY\(hyEND response is issued
or the S\(hyACTIVITY\(hyEND confirm is received.
.sp 1P
.LP
A.5.4.2
\fIVrsp and Vrspnb\fR
.sp 9p
.RT
.PP
These variables are used to resolve resynchronization collisions.
.PP
Vrsp indicates what kind of resynchronization is currently in
progress:
.RT
.LP
Vrsp\ =\ no
no resynchronization in progress,
.LP
Vrsp\ =\ a
resynchronize abandon,
.LP
Vrsp\ =\ r
resynchronize restart,
.LP
Vrsp\ =\ s
resynchronize set.
.PP
Vrspnb indicates the serial number in the case of resynchronize
restart.
.PP
Vrsp and, if necessary Vrspnb, are set when an S\(hyRESYNCHRONIZE request
is issued or an S\(hyRESYNCHRONIZE indication is received. Vrsp is set
to no when the SS\(hyuser goes to STA713.
.RT
.sp 1P
.LP
A.5.4.3
\fIVcoll\fR
.sp 9p
.RT
.PP
Vcoll is a boolean variable having the following values:
.RT
.LP
Vcoll\ =\ true:
a collision of S\(hyRELEASE requests has been
detected;
.LP
Vcoll\ =\ false:
there has not been a collision of S\(hyRELEASE
requests.
.PP
This variable is set false during the session connection
establishment phase.
.sp 1P
.LP
A.5.4.4
\fIV(A)\fR
.sp 9p
.RT
.PP
V(A) is used by the SS\(hyuser and is the lowest serial number to
which a synchronization point confirmation is expected. No confirmation is
expected when V(A)\ =\ V(M).
.RT
.sp 1P
.LP
A.5.4.5
\fIV(M)\fR
.sp 9p
.RT
.PP
V(M) is used by the SS\(hyuser and is the next serial number to be
used.
.RT
.sp 1P
.LP
A.5.4.6
\fIV(R)\fR
.sp 9p
.RT
.PP
V(R) is used by the SS\(hyuser and is the lowest serial number to
which resynchronization restart is permitted.
.bp
.RT
.sp 1P
.LP
A.5.4.7
\fIVsc\fR
.sp 9p
.RT
.PP
Vsc is a boolean variable having the following values:
.RT
.LP
Vsc\ =\ true:
the SS\(hyuser has the right to issue minor
synchronization point responses when V(A) is
less than V(M);
.LP
Vsc\ =\ false:
the SS\(hyuser does not have the right to issue minor
synchronization point responses.
.PP
Vsc is set false during the session connection establishment phase and
when an S\(hySYNC\(hyMINOR request is issued. Vsc is set true when an
S\(hySYNC\(hyMINOR indication is received.
.PP
\fINote\fR \ \(em\ Table A\(hy4/X.215 summarizes the operations on V(A),
V(M), V(R) and\ Vsc.
.RT
.sp 1P
.LP
A.5.4.8
\fIVdnr\fR
.sp 9p
.RT
.PP
Vdnr is a boolean variable having the following values:
.RT
.LP
Vdnr\ =\ true:
an S\(hyRELEASE confirm has been received in STA09
(following a collision of S\(hyRELEASE
requests);
.LP
Vdnr\ =\ false:
no S\(hyRELEASE confirm has been
received.
.PP
This variable is set to false during the connection establishment phase.
.ce
\fBH.T. [T31.215]\fR
.ce
TABLE\ A\(hy1/X.215
.ce
\fBEvents generated by the SS\(hyprovider\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(42p) | lw(138p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy1/X.215 [T31.215], p. 42\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T32.215]\fR
.ce
TABLE\ A\(hy2/X.215
.ce
\fBStates\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(42p) | lw(138p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy2/X.215 [T32.215], p. 43\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 25P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T33.215]\fR
.ce
TABLE\ A\(hy3/X.215
.ce
\fBEvents generated by the SS\(hyuser\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(42p) | lw(138p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy3/X.215 [T33.215], p. 44\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 16P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T34.215]\fR
.T&
lw(36p) | lw(84p) | lw(72p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
.T&
lw(36p) | lw(84p) | lw(72p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
T{
set to sn + 1
unchanged
unchanged
unchanged
SSYNmcnf
Vsc = false and V(M) > sn >= V(A)
T}
.T&
lw(36p) | lw(84p) | lw(72p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
T{
set to sn + 1
unchanged
unchanged
unchanged
SRSYNreq
r:V(M) >= sn >= V(R)
T}
.T&
lw(36p) | lw(84p) | lw(72p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
T{
unchanged
unchanged
unchanged
unchanged
SRSYNind
.
abandon
restart
set
unchanged
unchanged
unchanged
set to sn
unchanged
unchanged
unchanged
unchanged
unchanged
unchanged
unchanged
unchanged
SRSYNrsp
.line
SRSYNcnf
.line
a: sn as in SRSYNind
.line
r: sn as in SRSYNind
.line
s: sn <= 999999
.line
abandon
restart
set
set to sn
set to sn
set to sn
set to sn
set to sn
set to sn
0
unchanged
0
unchanged
unchanged
unchanged
SACTRreq
.line
SACTRind
.line
.
set to sn + 1
set to sn + 1
set to 1
unchanged
SACTSreq
.line
SACTSind
.line
.
set to 1
set to 1
set to 1
unchanged
SCONrsp+
.line
SCONcnf+
.line
.
sn present
set to sn
set to sn
0
false
sn:
synchronization point serial number quoted in session service
primitive.
.line
>=:
greater than or equal to.
.line
<=:
less than or equal to.
.line
*:
synchronization point serial number not equal to V(M) \(em 1 if major
synchronization or activity end outstanding.
T}
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy4/X.215 (\*`a l'italienne) [T34.215], p. 45\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T35.215]\fR
.ce
TABLE\ A\(hy5/X.215
.ce
\fBSpecific actions\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(24p) | lw(204p) .
.T&
lw(24p) | lw(204p) .
T{
Set V(M) = V(M) + 1
[24]
If Vsc = true, set V(A) = V(M). Set Vsc = false
T}
.T&
lw(24p) | lw(204p) .
T{
Set V(M) = V(M) + 1
[25]
Set V(A) = serial number + 1
[26]
Set V(A) = V(M) = V(R) = 1
[27]
Set V(A) = V(M) = serial number + 1. Set V(R) = 1
[28]
Set V(A) = V(M) = serial number
T}
.T&
lw(24p) | lw(204p) .
If Vrsp = a then set V(R) = 0
.T&
lw(24p) | lw(204p) .
If Vrsp = s then set V(R) = 0
.T&
lw(24p) | lw(204p) .
T{
Set Vrsp = no
[29]
Set the position of the tokens such that all available tokens are owned.
Set Vact = false
[30]
Set the position of the tokens such that all available tokens are not
owned. Set Vact = false
[31]
If Vsc false, set V(A) = V(M)
T}
.T&
lw(24p) | lw(204p) .
T{
Set V(M) = V(M) + 1
[32]
Set Vdnr = true
T}
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy5/X.215 [T35.215], p. 46\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 17P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T36.215]\fR
.ce
TABLE\ A\(hy6/X.215
.ce
\fBPredicates\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(24p) | lw(204p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy6/X.215 [T36.215], p. 47\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 10P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T37.215]\fR
.ce
TABLE\ A\(hy7/X.215
.ce
\fBConnection establishment state table\fR
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) .
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) .
T{
STA01\fR
SCONind
STA08
SCONreq
STA02A
SCONrsp+
.
[5] [11]
STA713
SCONrsp\(em
T}
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) .
STA01
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy7/X.215 [T37.215], p. 48\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.ce
\fBH.T. [T38.215]\fR
.ce
TABLE\ A\(hy8/X.215
.ce
\fBData transfer state table\fR
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
T{
STA713
SDTreq
.
p04
STA09
p03
STA10A
p03
STA10B
p03
STA713
SEXind
STA03
STA04A
STA04B
T}
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
T{
STA713
SEXreq
.
p09
STA09
p08
STA10A
p08
STA10B
p08
STA713
STDind
STA03
STA04A
STA04B
T}
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
T{
STA713
STDreq
.
p07
STA09
p06
STA10A
p06
STA10B
p06
STA713
T}
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy8/X.215 [T38.215], p. 49\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T39.215]\fR
.ce
TABLE\ A\(hy9/X.215
.ce
\fBSynchronization state table\fR
.T&
lw(30p) | lw(24p) | lw(24p) | lw(30p) | lw(24p) | lw(36p) | lw(36p) | lw(24p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy9/X.215 [T39.215], p. 50\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 6P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T40.215]\fR
.ce
TABLE\ A\(hy10/X.215
.ce
\fBResynchronization state table\fR
.T&
lw(36p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy10/X.215 [T40.215], p. 51\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 16P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T41.215]\fR
.ce
TABLE\ A\(hy10/X.215 (\fIconcluded\fR
.ce
)
.ce
\fBResynchronization state table\fR
.T&
lw(42p) | lw(36p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy10/X.215 (suite et fin) [T41.215], p. 52\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 17P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T42.215]\fR
.ce
TABLE\ A\(hy11/X.215
.ce
\fBActivity interrupt and discard state table\fR
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
STA11C\fR T{
STA11C\fR
STA11C
SACTDreq
p34&p39
STA05C
p39
STA05C
SACTDrsp
SACTIcnf
.
[29]
STA713
SACTIind
T}
.T&
lw(30p) | lw(24p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(30p) | lw(24p) .
STA11B T{
STA11B
STA11B
SACTIreq
p34&p39
STA05B
p39
STA05B
SACTIrsp
T}
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy11/X.215 [T42.215], p. 53\fR
.sp 1P
.RT
.ad b
.RT
.ce
\fBH.T. [T43.215]\fR
.ce
TABLE\ A\(hy11/X.215 (\fIconcluded\fR
.ce
)
.ce
\fBActivity interrupt and discard state table\fR
.T&
lw(36p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) .
.T&
lw(36p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) .
T{
STA11C
STA11C
STA11C
SACTDreq
p34&p39
STA05C
.
p34&p11
STA05C
p34&p39
STA05C
SACTDrsp
.
[30]
STA713
SACTIcnf
SACTIind
T}
.T&
lw(36p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) .
T{
STA11B
STA11B
STA11B
SACTIreq
p34&p39
STA05B
.
p34&p11
STA05B
p34&p39
STA05B
SACTIrsp
.
[30]
STA713
T}
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy11/X.215 (suite et fin) [T43.215], p. 54\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T44.215]\fR
.ce
TABLE\ A\(hy12/X.215
.ce
\fBActivity start, resume and capability data state table\fR
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) .
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) .
T{
STA22
SCDreq
.
p47
STA21
SCDrsp
T}
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) .
STA713
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy12/X.215 [T44.215], p. 55\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 20P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T45.215]\fR
.ce
TABLE\ A\(hy13/X.215
.ce
\fBToken management and exceptions state table\fR
.T&
lw(36p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy13/X.215 [T45.215], p. 56\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 15P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T46.215]\fR
.ce
TABLE\ A\(hy13/X.215 (\fIconcluded\fR
.ce
)
.ce
\fBToken management and exceptions state table\fR
.T&
lw(42p) | lw(36p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
.T&
lw(42p) | lw(36p) | lw(42p) | lw(36p) | lw(36p) | lw(36p) .
STA21 T{
STA713
SPTreq
.
p53
STA22
p53
STA713
SUERind
STA19
.
p50
STA713
p51
STA20
SUERreq
.
p50
STA19
T}
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy13/X.215 (suite et fin) [T46.215], p. 57\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 7P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T47.215]\fR
.ce
TABLE\ A\(hy14/X.215
.ce
\fBConnection release state table\fR
.T&
lw(42p) | lw(42p) | lw(42p) | lw(42p) | lw(42p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau A\(hy14/X.215 [T47.215], p. 58\fR
.sp 1P
.RT
.ad b
.RT
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation X.215)
.sp 9p
.RT
.ce 0
.ce 1000
\fBUsage of the generalized OSI session service to achieve\fR
.sp 1P
.RT
.ce 0
.ce 1000
\fBcompatibility with Basic T.62\fR
.ce 0
.LP
B.1
\fICompatibility requirements\fR
.sp 1P
.RT
.PP
Recommendation T.62 for the Basic Teletex Service was adopted by
the CCITT in 1980 and has been used in a number of products available or
under development.
.PP
It is of essential importance that the existing and future Telematic terminals
and systems must be able to interact with OSI\(hySystems.
.PP
This was one of the main guidelines for the development of the
generalized OSI session protocol which has been conducted in very close
cooperation between CCITT and ISO during the last two years of the 1981\(hy84
study period.
.PP
This Annex shows how
compatibility between OSI generalized session protocol and the basic T.62
can be achieved.
.bp
.RT
.sp 1P
.LP
B.2
\fIPrinciples for ensuring compatibility\fR
.sp 9p
.RT
.PP
The compatibility requirements outlined in the previous section
impose that systems using OSI protocols can interact with terminals using
Telematic protocols.
.PP
The layered structure of both protocols which conforms with the OSI
Reference Model and the full compatibility of the transport\(hyoriented layer
protocols limits the problem of compatibility to the protocols above the
transport\(hyoriented layers.
.PP
As far as the higher layer protocols are concerned, the principles
used to ensure the required compatibility are the following:
.RT
.LP
a)
The functions of T.62 usable directly in a generalized
session protocol are identified.
.LP
b)
These functions and the corresponding protocol elements
are integrated in the generalized OSI session protocol which
must remain consistent and to continue to satisfy the various
requirements of a generalized OSI session protocol.
.LP
c)
The additional matters in T.62 related to the particular
services and to T.61 are placed in the presentation and
application layer on the top of the OSI session protocol. With
appropriate application rules using the session services, the
T.62 protocol elements can be generated.
.PP
The usage rules of the generalized session service are described in the
next section followed by the explanation of how these translate
precisely in basic T.62, thus ensuring the required compatibility.
.sp 1P
.LP
B.3
\fIUsage session service to ensure compatibility with basic T.62\fR
.sp 9p
.RT
.PP
The following rules specify how an OSI session user entity has to use the
generalized session service to give full T.62 basic Teletex/Facsimile service
(see also Figures\ B\(hy1/X.215 and\ B\(hy2/X.215).
.RT
.PP
The BAS subset of the generalized session service must be
used.
.PP
Only the following service primitives must be used:
.RT
.LP
S\(hyCONNECT
.LP
S\(hyRELEASE
.LP
S\(hyU\(hyABORT
.LP
S\(hyP\(hyABORT
.LP
S\(hyACTIVITY\(hySTART
.LP
S\(hyACTIVITY\(hyRESUME
.LP
S\(hyACTIVITY\(hyEND
.LP
S\(hyACTIVITY\(hyINTERRUPT
.LP
S\(hyACTIVITY\(hyDISCARD
.LP
S\(hySYNC\(hyMINOR
.LP
S\(hyU\(hyEXCEPTION\(hyREPORT
.LP
S\(hyP\(hyEXCEPTION\(hyREPORT
.LP
S\(hyCONTROL\(hyGIVE
.LP
S\(hyTOKEN\(hyPLEASE
.LP
S\(hyCAPABILITY DATA
.LP
S\(hyDATA
.PP
The data taken must be available.
.PP
\fINote\fR \ \(em\ Minor sync and major/activity tokens are always available
in BAS. The release token is not available.
.RT
.sp 1P
.LP
B.3.1
\fISession connection establishment phase\fR
.sp 9p
.RT
.PP
The session service user initiates a session connection by using
the S\(hyCONNECT request primitive.
.PP
The acceptor SS\(hyuser may accept or refuse the connection with the
S\(hyCONNECT response primitive. When accepting the connection the SS\(hyUSER
may
request the control by issuing a S\(hyTOKEN\(hyPLEASE request primitive (see
\(sc\ B.3.5).
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure B\(hy1/X.215, (M), p. 59\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure B\(hy2/X.215, (M), p. 60\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
Parameters of the S\(hyCONNECT primitives are used in the following
way:
.RT
.LP
\(em
Connection identifier: supplied by the user in the request
and response, its format is the same as defined in T.62
(calling or called terminal identifier, date and time,
additional session reference number).
.LP
\fINote\fR \ \(em\ The four fields of the connection identifier have
lengths as identified in Recommendation\ F.200.
.LP
\(em
Calling and called SSAP addresses: the session layer
addressing is not used by T.62 equipments.
.LP
\(em
Quality of service:
.LP
\(em
no extended control (i.e. no transport expedited)
.LP
\(em
no optimized dialogue transfer (i.e. basic
concatenation)
.LP
\(em
other parameters, if available, must be set in order to
select class 0 of the transport protocol.
.LP
\(em
Session requirements: the following functional units have to
be selected:
.LP
\(em
Synchronization minor
.LP
\(em
Activity management
.LP
\(em
Capability data
.LP
\(em
Half duplex
.LP
\(em
Exceptions.
.LP
\(em
Initial assignment of tokens: all the available tokens are
assigned to the initiator.
.LP
\(em
User data: this parameter contains the following information
(see also \(sc\ B.5):
.LP
\(em
miscellaneous session capabilities
.LP
\(em
window size (to be negotiated according to the rules
defined in T.62)
.LP
\(em
service identifier
.LP
\(em
non basic terminal capabilities.
.LP
\(em
Result: (in response/confirmation) this parameter is used to
accept or refuse the session connection.
.LP
In case of refusing the connection, a Reason (session)
information may be present in the user data.
.sp 1P
.LP
B.3.2
\fISession connection termination phase\fR
.sp 9p
.RT
.PP
The session connection can be terminated by means of the S\(hyRELEASE primitives
(orderly release) or S\(hyU\(hyABORT/S\(hyP\(hyABORT primitives.
.PP
Only the initiator of the session connection is allowed to release it by
using S\(hyRELEASE request.
.PP
No user data have to be supplied and the result parameter in
response/confirmation indicates acceptation of the release (since the release
token is not available, there is no way to refuse the release).
.PP
When requesting S\(hyU\(hyABORT, the user data parameter must be absent.
.PP
Re\(hyuse of the transport connection is a local implementation choice,
and does not appear at the session service level.
.RT
.sp 1P
.LP
B.3.3
\fIDocument management\fR
.sp 9p
.RT
.PP
The T.62 document concept is equivalent to the BAS activity concept where
the activity identifier is the document number.
.PP
The SS\(hyuser will use the S\(hyACTIVITY\(hySTART and S\(hyACTIVITY\(hyRESUME
primitives to start or resume documents; when resuming a previously interrupted
document it is up to the user to supply and control the linking informations.
.PP
The SS\(hyuser terminates a document by using the S\(hyACTIVITY\(hyEND
confirmed service.
.PP
Documents may be interrupted or discarded by using the
S\(hyACTIVITY\(hyINTERRUPT or S\(hyACTIVITY\(hyDISCARD services.
.bp
.RT
.sp 1P
.LP
B.3.3.1
\fIS\(hyACTIVITY\(hySTART\fR
.sp 9p
.RT
.LP
\(em
Activity identifier: this parameter contains the document
reference number.
.LP
\(em
User data: this parameter contains the non basic terminal
capabilities, the document type identifier, the service
interworking identifier encoded as defined in T.62.
.sp 1P
.LP
B.3.3.2
\fIS\(hyACTIVITY\(hyRESUME\fR
.sp 9p
.RT
.LP
\(em
Activity identifier: this parameter contains the document
reference number.
.LP
\(em
Old activity identifier is the same activity identifier that
had been supplied when the activity had been started.
.LP
\(em
The old session connection identifier identifies the session
in which the activity had been started, it must contain the
calling terminal identifier, the called terminal identifier,
date and time and additional session reference number.
.LP
\(em
The user data parameter must contain the non basic terminal
capabilities, the document type identifier, the service
interworking identifier encoded as in T.62.
.LP
\fINote\fR \ \(em\ It is the responsibility of the receiving terminal to
discard any user information that has been duplicated in the process of
continuation of an interrupted activity.
.sp 1P
.LP
B.3.3.3
\fIS\(hyACTIVITY\(hyEND\fR
.sp 9p
.RT
.LP
\(em
Synchronization point serial number (request/indication): the
last checkpoint reference number of the document.
.LP
\(em
No user data are supplied.
.PP
The SS\(hyuser must not use S\(hyACTIVITY\(hyEND request immediately after
having requested a minor synchronization point (in T.62 data must be sent
between the last page boundary and the end of the document).
.PP
To refuse the checkpoint indicated in S\(hyACTIVITY\(hyEND indication,
the SS\(hyuser shall use the U\(hyUSER\(hyEXCEPTION\(hyREPORT service.
.PP
When activating the S\(hyACTIVITY\(hyEND response primitive, the receiving
SS\(hyuser indicates that:
.RT
.LP
\(em
it has not detected any error
.LP
\(em
it accepts responsibility for the received document
.LP
\(em
it is ready to receive a new S\(hyACTIVITY\(hySTART or
S\(hyACTIVITY\(hyRESUME indication.
.sp 1P
.LP
B.3.3.4
\fIS\(hyACTIVITY\(hyDISCARD\fR
.sp 9p
.RT
.PP
The S\(hyACTIVITY\(hyDISCARD request primitive shall be used to indicate
to the remote entity, the abnormal ending of a document and that the receiver
of S\(hyACTIVITY\(hyDISCARD indication is not held responsible for the
part of the
document received so far.
.PP
\fINote\fR \ \(em\ S\(hyACTIVITY\(hyDISCARD indication is an invitation
to discard
the whole of the document.
.PP
The S\(hyACTIVITY\(hyDISCARD response primitive shall be used to acknowledge
the S\(hyACTIVITY\(hy
DISCARD indication and to indicate that the SS\(hyuser is ready to receive
a new S\(hyACTIVITY\(hyBEGIN indication.
.PP
The SS\(hyuser may use the reason parameter in the S\(hyACTIVITY\(hyDISCARD
primitives, only the following reasons shall be indicated:
.RT
.LP
a)
local terminal error
.LP
b)
unrecoverable procedural error
.LP
c)
no specific reason stated.
.bp
.sp 1P
.LP
B.3.3.5
\fIS\(hyACTIVITY\(hyINTERRUPT\fR
.sp 9p
.RT
.PP
The S\(hyACTIVITY\(hyINTERRUPT request shall be used to indicate to the
remote entity the point of resynchronization and to abnormally end the
document transfer in progress.
.PP
The S\(hyACTIVITY\(hyINTERRUPT response primitive shall be used to
acknowledge the S\(hyACTIVITY\(hy
INTERRUPT indication. It confirms to the
initiator
of S\(hyACTIVITY\(hyINTERRUPT that the receiver has already accepted responsibility
for the received document (up to the last synchronization point for which
a
positive acknowledgement has been sent).
.PP
Linking of parts of an interrupted document is a local operation at
the receiver and is therefore not within the responsibility of the session
service provider. The SS\(hyuser may use the reason parameter in the
S\(hyACTIVITY\(hyINTERRUPT primitive, only one of the following reasons
shall be
indicated:
.RT
.LP
a)
local terminal error
.LP
b)
unrecoverable procedural error
.LP
c)
no specific reason stated.
.sp 1P
.LP
B.3.4
\fISynchronization\fR
.sp 9p
.RT
.PP
The SS\(hyuser will not request major synchronization (since the
S\(hySYNC\(hyMAJOR primitive has not been selected during session connection
establishment phase).
.PP
In the basic Teletex service, a minor synchronization point must be
inserted at each page boundary using the S\(hySYNC\(hyMINOR request primitive.
.PP
The user will use only the minor synchronization service with explicit
confirmation requested.
.PP
The SS\(hyuser must not request an end of activity or a minor
synchronization point immediately after having requested a minor
synchronization point.
.PP
The maximum window size may be negotiated during session connection
establishment by using the user data parameter of the S\(hyCONNECT primitive.
(The negotiation rules are defined in T.62).
.PP
The sender (i.e. the owner of all the tokens) is permitted to recover from
an interrupted transmission at only one of two points:
.RT
.LP
a)
A cancellation is achieved by the subsequent use of
S\(hyACTIVITY\(hyRESUME request and S\(hyACT\(hyDISCARD request and the
transmission will be resumed by the S\(hyACTIVITY\(hySTART
request.
.LP
b)
The sender may resume by use of S\(hyACTIVITY\(hyRESUME starting
at the last minor sync point for which an S\(hySYNC\(hyMINOR
confirmation was received.
.PP
On this basis, the receiver must be able to resume reception
at a minor sync point ranging from the last acknowledged
sync point, to the last acknowledged sync point plus one minus
the window size.
.PP
The S\(hySYNC\(hyMINOR request primitive is used to indicate the
boundary between pages and it also indicates a checkpoint for
error recovery purposes. The S\(hySYNC\(hyMINOR indication invites the
SS\(hyuser to accept responsibility for the previously received
page.
.PP
The S\(hySYNC\(hyMINOR response shall be used to indicate that the
user accepts responsibility for the page and acknowledges the
minor sync point. Each minor sync point must be explicitly
acknowledged.
.PP
\fINote\fR \ \(em\ The rules (i.e. the state machine) to use the session
service for synchronization are unaffected by the inclusion or exclusion
of the synchronization window mechanism within/from the session layer.
.RT
.sp 1P
.LP
B.3.4.1
\fIS\(hySYNC\(hyMINOR\fR
.sp 9p
.RT
.LP
\(em
Type (request/indication): this parameter must indicate that explicit
confirmation is requested.
.LP
\(em
Synchronization point serial number:
(indication/response/confirm) check point number.
.bp
.LP
\(em
No user data must be supplied in the request.
.LP
\(em
The user data must be supplied in the response with the first octet encoded
as follows:
.LP
0\ \ further traffic can be accepted
.LP
1\ \ ability to receive further traffic is jeopardized.
.sp 1P
.LP
B.3.4.2
\fIS\(hyU\(hyEXCEPTION\(hyREPORT\fR
.sp 9p
.RT
.LP
\(em
Reason:
.LP
a)
SS\(hyuser receiving ability jeoparidized
.LP
b)
local SS\(hyuser error
.LP
c)
sequence error
.LP
d)
unrecoverable procedural error
.LP
e)
non\(hyspecific error
.LP
\(em
User data parameter must not be supplied.
.PP
The receiver of a document may issue an S\(hyU\(hyEXCEPTION\(hyREPORT
request at any time after having received an S\(hySYNC\(hyMINOR indication, or
S\(hyACTIVITY\(hyEND indication instead of giving the confirmation.
.PP
When receiving an S\(hyU\(hyEXCEPTION\(hyREPORT indication or
S\(hyP\(hyEXCEPTION\(hyREPORT indication, the user must request the S\(hyACTIVITY\(hyINTERRUPT
or S\(hyACTIVITY\(hyDISCARD services.
.RT
.sp 1P
.LP
B.3.5
\fIControl exchange\fR
.sp 9p
.RT
.PP
The S\(hyCONTROL\(hyGIVE service is used to give all the available
tokens. This can only be used when no activity is in progress. The control
give service is unconfirmed (although it is confirmed at the protocol level).
.RT
.sp 1P
.LP
B.3.5.1
\fIS\(hyTOKEN\(hyPLEASE\fR
.sp 9p
.RT
.PP
Must only be used to request all the available tokens by requesting only
the data token.
.PP
When receiving an S\(hyTOKEN\(hyPLEASE indication with data token parameter,
the SS\(hyUSER may give the control by requesting the give control service.
.RT
.sp 1P
.LP
B.3.5.2
\fIS\(hyCONTROL\(hyGIVE\fR
.sp 9p
.RT
.PP
There is no parameter associated with these service
primitives.
.RT
.sp 1P
.LP
B.3.5.3
\fIS\(hyTOKEN\(hyPLEASE\fR
.sp 9p
.RT
.PP
Tokens: data token only to demand control.
.PP
No user data.
.RT
.sp 1P
.LP
B.3.6
\fIData transfer phase\fR
.sp 9p
.RT
.PP
The S\(hyDATA service must be used to send user information only
within an activity.
.RT
.sp 1P
.LP
B.3.7
\fICapability exchange\fR
.sp 9p
.RT
.PP
The document capability list is exchanged by using the
S\(hyCAPABILITY\(hyDATA primitives.
.PP
The list of the capability parameters is described in T.62, \(sc\ 3.4.5,
and these parameters are supplied by means of the user data parameter of
the
S\(hyCAPABILITY\(hyDATA primitives.
.bp
.RT
.sp 1P
.LP
B.4
\fIUsage of the session service to ensure compatibility with\fR
\fInon basic T.62\fR
.sp 9p
.RT
.PP
The following rules specify how an OSI session service user has to use
the generalized session service to ensure compatibility with non basic
T.62 (i.e.\ extension for interactive mode, typed data facility and duplex
exchanges).
.PP
The rules for ensuring compatibility with basic T.62 remain unchanged except
for the services described in this section.
.PP
The following additional service primitives may be used:
.RT
.LP
S\(hyTOKEN\(hyGIVE
.LP
S\(hyTYPED\(hyDATA
.sp 1P
.LP
B.4.1
\fIConnection establishment phase\fR
.sp 9p
.RT
.PP
For pure interactive mode, the BCS subset must be
selected.
.PP
For interactive mode with document transfer, the BAS subset must be
selected.
.PP
The SS\(hyuser indicates in the session requirements parameter which of
the duplex and half duplex functional units is selected.
.PP
He may optionally propose the use of the typed data functional
unit.
.RT
.sp 1P
.LP
B.4.2
\fITokens exchange\fR
.sp 9p
.RT
.PP
Tokens are never exchanged when an activity is in progress.
.PP
The S\(hyCONTROL\(hyGIVE service can be used to give all the available
tokens outside activities. This service may not be used if pure interactive
mode has been selected at the session establishment phase.
.PP
The S\(hyGIVE\(hyTOKEN service must be used to provide interactive token
exchange (i.e.\ unconfirmed at the protocol level). All the available tokens
must be given when invoking this service. The S\(hyPLEASE\(hyTOKEN service
is used to request all the available tokens (by requesting either data,
sync minor and
major tokens or only the data token).
.RT
.sp 1P
.LP
B.4.3
\fIData transfer\fR
.sp 9p
.RT
.PP
When interactive mode with document transfer is selected, data may be sent
inside and outside activities.
.PP
When the duplex functional unit is selected, data may be sent by both users
outside activities. Only the SS\(hyuser who owns the minor sync token and
major/activity token is allowed to send data when an activity is in
progress.
.PP
S\(hyTYPED\(hyDATA service may be used if the corresponding functional
unit has been selected at connection establishment.
.RT
.sp 1P
.LP
B.4.4
\fIException reporting\fR
.sp 9p
.RT
.PP
In the case of an error occurring during an interactive phase
(i.e.\ outside an Activity in BAS, or in BCS), only the S\(hyU\(hyABORT
service can be used to resolve it.
.RT
.sp 1P
.LP
B.5
\fIHandling of T.62 PIs and PGIs not defined within the OSI\fR
\fIsession layer\fR
.sp 9p
.RT
.PP
Recommendation T.62 defines a number of PIs and PGIs which are not part
of the OSI session layer. Some of them are considered as components of
valid session SPDUs. For example, Calling Terminal Identifier, Date and Time
and Additional Session Reference Number are components of the Session
Connection Identifier Parameter of the CONNECT SPDU.
.PP
Although the others are recognized within the session layer
specification, they are not defined in the OSI session protocol. Therefore,
local conventions are needed in order to ensure that the corresponding
protocol elements are generated and received in accordance with
Recommendation\ T.62.
.bp
.PP
The SPDUs and parameters which are subject to such conventions are
listed in Table\ B\(hy1/X.215.
.RT
.ce
\fBH.T. [T48.215]\fR
.ce
TABLE\ B\(hy1/X.215
.ce
\fBS.62 Parameters subject to local conventions\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
CONNECT ACCEPT REFUSE ACTIVITY\(hySTART ACTIVITY\(hy RESUME CAPABILITY DATA CAPABILITY DATA ACK
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
T{
Non\(hybasic session capabilities
T} X X X . . . .
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
Service identifier X X X . . . .
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
Inactivity timer X X . . . X X
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
T{
Service interworking identifier
T} . . . X\fR X . .
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
Acceptance of CDCL parameters . . . . . . X
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
T{
Storage capability negotiation
T} . . . . . X X
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
Document type identifier . . . X X . .
_
.T&
lw(60p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
T{
Non\(hybasic teletex terminal capabilities
T} X X X X X X X
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau\ B\(hy1/X.215 [T48.215], p. 61\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 21P
.sp 2P
.LP
\fBMONTAGE:\ \ \fR Rec. X.216 sur le reste de cette page
.sp 1P
.RT
.LP
.bp